1. Field of the Invention
This invention relates to data protection and, more particularly, to techniques for reconstructing deleted snapshot copies of a data volume.
2. Description of the Related Art
Many business organizations and governmental entities rely upon applications that access large amounts of data, often exceeding a terabyte or more of data, for mission-critical applications. It is common that many such applications require near-continuous access. For example, many systems such as retail processing databases, airline reservation databases, and financial institution databases must be available to perform transaction processing 24 hours a day. Downtime associated with such systems can be disastrous.
With the growing amounts of data and shrinking acceptable downtime requirements of modem systems, organizations are sometimes forced to choose between the conflicting demands associated with modem systems. For example, secondary operations such as data backup operations, reporting and analysis, and application testing can be of significant importance. However, such secondary operations can interrupt or encumber the normal transaction processing of a host system running a database application.
To minimize these problems, some systems support snapshot capabilities that allow point-in-time copies of data to be created. By creating snapshots of the appropriate storage devices, a frozen image of the volume can be created and can then be used to facilitate the secondary operations. For example, the snapshot copies containing the image can be installed on a secondary host that performs the secondary operations. In this manner, availability of the primary host for normal transaction processing can be maximized.
The creation of snapshot copies can be based on data-mirroring technology implemented by a volume manager running on the host system. In a data mirroring configuration, identical copies of data are stored on different physical storage devices. A volume-level snapshot can be created simply by splitting and detaching a mirror containing an image of the data from the original volume. Once the user has completed use of the snapshot volume split from an original, it may be resynchronized (since continued updates to the original volume may have occurred) by reattaching it to the original. Subsequent snapshots may be taken in a similar manner.
While the volume level snapshot capabilities of a volume manager may be utilized to create a snapshot of a data volume, several significant problems may be presented. Snapshots are typically kept online (e.g., in a quickly accessible storage media such as a local disk drive). Accordingly, snapshots can typically be accessed much more quickly than backups, which are typically kept in an offline storage media (e.g., a tape within a tape library). Thus, if a data error can be corrected from a snapshot, the recovery may be much less time-consuming than if the data error can only be corrected from a backup. However, since there is usually a limited amount of online storage space, the number of snapshots that can be maintained is fairly small. Thus, in many systems, the oldest snapshot may be deleted in order to free room for a newer snapshot.
Some systems may provide enough online storage to store a relatively large number of snapshots. These systems may provide additional history through snapshots, allowing more data recovery to take place via online snapshots as opposed to offline backups. However, managing a large number of snapshots may be undesirably complex. If the snapshots are managed by software, the software may require more system resources than the user applications running on the system. Accordingly, the complexity and overhead of snapshot management may itself limit the number of snapshots maintained by a system. It is desirable to be able to gain the added protection provided by maintaining larger numbers of snapshots without the associated overhead and storage constraints.